PC-Blue - MS DOS Public Domain Library/PC-Blue MS-DOS Public Domain Library - NYACC.iso/vol045/bullet4

Text File | 1987-01-11 | 9.4 KB | 181 lines

              XMODEM File Transfer Protocol

                    By Larry Jordan

When transferring files between computers using the telephone
system, there is always the chance that electrical noise will
result in data transmission errors. To ensure proper transfer of
files it is necessary to detect data transmission errors and to
retransmit data that contains errors. Most people think that
asynchronous parity error detection provides that capability. It
does not. Parity error detection does tell you when a data
transfer error has occurred, but it is up to you to retransmit
the data to correct errors. The problem is that parity error
detection is not actually performed by most IBM PC communication
packages. If a package does perform the error detection, it may
not inform you of errors in such a way that you know to
immediately retransmit the data. ASCOM, for example, places an
asterisk in a file where parity errors are detected, but you
may not realize the errors occurred until long after the file is
transferred. To ensure "error-free" data transfer you need a
protocol file transfer technique. Andrew Fluegelman has added
such a technique to PC-TALK.III called the XMODEM protocol.

A protocol is a set of rules and conventions that apply to a
specific area of communications that allow participants to
properly communicate regardless of the hardware brand or software
package being used. The protocol file transfer is a set of rules
for transferring files which specifies a set of ASCII handshaking
characters and the sequence of handshaking required to perform
certain file transfer functions. Protocol handshaking signals
allow communication software to transfer text, data and machine
code files, and to perform sophisticated error-checking. The
handicap in using protocol file transfer techniques is that the
computers on both ends of the communications link must be using
compatible software; there is no standard that controls these
protocols and almost all communication packages that have a
protocol file transfer option use a protocol unique to that
package. This means that a business or group of people must
standardize its microcomputer communications software to take
advantage of protocol transfers.

The Ward Christensen XMODEM protocol is one specific file
transfer protocol that may become a default standard in personal
communications because of its widespread use on  bulletin
boards and because of its inclusion in low cost personal computer
communication packages such as PC-TALK. It has not gained
widespread acceptance in business communication packages partly
because the protocol is public domain; most business
communication package designers use unique protocols to force
businesses to use their software on both ends of communication
links. By providing you with this insight into protocol transfer
and explaining in detail the operation of the XMODEM protocol, I
hope to add momentum to the development of a "standard protocol"
whether it be the XMODEM model or some other model. Users of
communication software deserve a standard protocol that will
allow them to use the technique with any microcomputer regardles
of the software packages employed.

The XMODEM protocol is illustrated in Figure 1. As you can see
from that figure, XMODEM does not begin the transfer of data
until the receiving computer signals the transmitting computer
that it is ready to receive data. The Negative Acknowledge (NAK)
character is used for this signal and is sent to the transmitting
computer every 10 seconds until the file transfer begins. If the
file transfer does not begin after 9 NAK's are sent, the process
has to be manually restarted.

After a NAK is received, the transmitting computer uses a Start
of Header (SOH) character and two block numbers (a true block
number followed by a 1's complement of the number) to signal the
start of a 128-byte block of data to be transferred then sends
the block followed by an error-checking checksum.  The checksum
is calculated by adding the ASCII values of each character in the
128 character block; the sum is then divided by 255 and the
remainder is retained as the checksum.  After each block of data
is transferred, the receiving computer computes its own checksum
and compares the result to the checksum received from the
transmitting computer.  If the two values are the same, the
receiving computer sends an Acknowledge (ACK) character to tell
the receiver to send the next sequential block.  If the two
values are not the same, the receiving computer sends the
transmitter an NAK to request a retransmission of the last block
This retransmission process is repeated until the block of data
is properly received or until 9 attempts have been made to
transmit the block.  If the communications link is noisy,
resulting in improper block transmission after 9 attempts, the
file transfer is aborted.

XMODEM uses two block numbers at the start of each block to be
sure the same block is not transmitted twice because of a
handshake character loss during the transfer. The receiving
computer checks the transmitted block to be sure that it is the
one requested and blocks that are retransmitted by mistake are
thrown away. When all data has been successfully transmitted, the
transmitting computer sends the receiver an End of Transmission
(EOT) character to indicate the end of file.

The XMODEM protocol offers the IBM PC several advantages over other
protocols and file transfer methods. First, the protocol is in
the public domain which makes it readily available for software
designers to incorporate into a communications package. Second,
the protocol is easy to implement using high level languages such
as BASIC or Pascal. Third, the protocol only requires a 256-byte
communication receive buffer which makes it attractive for IBM PC
owners who only have 64K systems. Forth, the protocol allows a
user to transfer non-ASCII 8-bit data files (i.e., COM, EXE and
tokenized BASIC) between microcomputers because it calculates the
end of a file based on file size and uses handshake signals to
indicate the end of a file instead relying on an end of file
marker character (control-Z) to terminate a file transfer.
Fifth, XMODEM error-checking is superior to normal asynchronous
parity error checking.  The parity method of error-checking is
95% effective if the software on the receiving end checks for
parity errors.  XMODEM error-checking is 99.6% effective, and the
software on the receiving end must check for errors.  Parity
errors detected also do not result in automatic retransmission of
the bad data; XMODEM detected errors result in data
retransmission until no errors are detected or until 9
retransmissions have been attempted.  Finally, the protocol is
used by many CP/M bulletin boards and having the protocol in a
communications package allows the IBM PC user to receive
error-checked files from these bulletin boards.

Andrew Fluegelman has given the XMODEM protocol a real boost in
the IBM PC world by including it in his package. He has also
added significant power to the package by including the protocol
Rumor has it that Don Withrow will soon add to the XMODEM
momentum by adding it to his HOSTCOMM software package. Keep up
the good work guys -- we will get a standard one way or the
other!

[This article was derived from material contained in a book
written by Larry Jordan and Bruce Churchill to be published this
Summer by The Brady Company. The article will also be in the
5th issue of PC World magazine.]



             XMODEM Protocol File Transfer


Receiving                                      Transmitting
Computer                                         Computer
Ready to                                         Ready to
Receive                                          Transmit
   |                                                |
   |                                                |
   |---------------------\NAK\--------------------->|
   |                                                |
   |<------/SOH/Blk #1/Blk #1/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<------/SOH/Blk #2/Blk #2/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<------/SOH/Blk #3/Blk #3/Garbled Data/CkSum/---|
   |                                                |
   |---------------------\NAK\--------------------->|
   |                                                |
   |<------/SOH/Blk #3/Blk #3/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<--------------------/EOT/----------------------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   V                                                V

  File                                             File
Receipt                                          Transmit
  Ends                                             Ends

                           Figure 1


-------------------------------------------------------------------